【セッションレポート】ミッションクリティカルシステムを AWS に載せるには？ #AWSSummit

はじめに

AWS Summit Tokyo に参加しました！

2日目 AWS-43 「ミッションクリティカルシステムを AWS に載せるには？」のセッションレポートを投稿いたします。

セッション視聴

AWS Summit Tokyoの登録を行うことでオンデマンドで視聴可能です。（現地参加された方は改めての登録は不要です。）

登録済みの場合、以下から直接遷移できます。

https://jpsummit.awsevents.com/public/session/view/562

セッション概要

高可用性を求めるシステムを AWS に載せるにはコツがあります。 AWS のアーキテクチャから始まって、どのような点に気をつけなければいけないのか、どのように工夫することでどこまで対応できるのかを説明します。 AWSの障害が気になって AWS 上で重要なシステムの構築に踏み出せないエンジニアの方に見ていただきたいと思います。 マルチ AZ でどこまで対応できるのか、マルチリージョンの構成が有効なケース、代表的なグローバルサービスの障害とその対策といった内容をご紹介します。

得られること

• 静的安定性というAWS内で培われた高可用性の特性があり、AWSサービスの可用性を支えているだけでなく、ユーザ側でも活かせること
• AWS内の静的安定性、マルチAZなどの冗長化、ユーザ側の静的安定性の組み合わせでかなりの障害ケースに対応できること
• 静的安定性は、どのようなシステムにも重要な特性である

アジェンダ

• アーキテクチャの検討と可用性
• 静的安定性とは
• リソースレベルの可用性
• AWSサービスレベルの可用性
• リージョンを越える範囲の可用性

セッションレポート

アーキテクチャの検討と可用性

• ミッションクリティカルシステムとAWS
  • オンプレミスをイメージされることが多い
• システム企画や設計、アーキテクチャ
  • 機能要件と非機能要件を整理する上で重要なのが、アーキテクチャ
• 本日のフォーカスポイント
  • アーキテクチャと可用性をフォーカス
• ミッションクリティカルシステムとは
  • ミッションクリティカル = 重要なサービスを提供し続ける
• 可用性観点でアーキテクチャを評価する
  • ミッションクリティカルシステムを中心に、可用性観点でのアーキテクチャ評価は様々なものが行われてきた
  • システムを部分(コンポーネント)に分解
• 検討するシステムコンポーネント一覧
  • インスタンス（リソース）
  • AWS サービス(ゾーナルサービス)
  • AWS サービス(リージョナルサービス)
  • AWS サービス(グローバルサービス)
  • ネットワーク
    • 上記には、どのようなアプローチが有効か解説する

静的安定性とは

• 静的安定性
  • 他のサービスが障害になっても、システムが影響を受けずに稼働する
  • 障害時に設定変更する必要がなく、何もしなくても稼働を続ける
• 可用性は重要
  • 静的安定性は、そのためにAWS内部で長年かけて培ったもの
  • AWS利用者のメリット
    • AWSサービスの可用性
    • システムの可用性が向上
    • 手作業不要、運用自動化
• 静的安定性とミッションクリティカルシステムの関係
  • 静的安定性は、可用性を強化するもの
  • ミッションクリティカルシステムは、止められないシステム
    • 上記の関係から、静的安定性は、ミッションクリティカルシステムに役立つ
• 静的安定性の前提となるAWSアーキテクチャの紹介
  • AWSサービスの殆どは、コントロールプレーンとデータプレーンで構成されている
  • コントロールプレーンとデータプレーンの連携
    1. EC2を作成するAPIを実行
    2. コントロールプレーンで処理
    3. データプレーンに連絡される
    4. データプレーン内にEC2が起動する
    5. EC2が稼働する
  • コントロールプレーンとは
    • 管理を担当するモジュール。リソースの作成や変更など。
    • 障害が避けられない。
  • データプレーンとは
    • リソース稼働のためのモジュール
    • 統計的に障害が発生しにくい
  • コントロールプレーンとデータプレーンは疎結合
    • コントロールプレーンが障害になっても、作成済みのリソースが普段の処理を行うことができます。
• AWSサービスとユーザ側の静的安定性
  • 障害時にコントロールプレーンに新規作成や設定変更などを依頼しない
  • 障害復旧時に手作業などの特別なアクションを必要ないようにする

リソースレベルの可用性

• リソースレベル EC2 RDS
  • コンピュートのH/W障害などに備えた冗長化。
  • マルチAZ構成を選択

AWSサービスレベルの可用性

• AWS サービス単体の可用性
  • 可用性の高い設計、AWSサービス内の静的安定性
• 目標となる可用性と冗長化
  • 可用性目標の実装例
    • 99%, 99.9%, 99.99%のシナリオ
• マルチAZ構成
  • AZを２つ
  • ELB
  • RDS マルチAZ
• 99.99%の可用性目標
  • 3AZの構成
  • ピーク性の50%
    • １つのAZがダウンしても、他の2つのAZで100%となる
  • 障害に耐えるためのコントロールプレーンへの変更を必要としない
• 複数リージョン
  • 東京リージョンで稼働
  • 大阪リージョンは、スタンバイ
  • RDSはレプリケーション
    • リージョン同士は独立しているため、複数リージョン構成でデータプレーンの障害に耐えるといった高い可用性を得られることが分かる
• まとめ
  1. AWS内の静的安定性でAWSサービスは可用性が高い
  2. 冗長化で可用性を高くできる
  3. ユーザ側の静的安定性で可用性を高くできる
• 1.は3.を活かしている
• 2.と3.どちらも意識するべき

リージョンを越える範囲の可用性

• リージョンを超えて考える
  • グローバル・サービス、利用者とのネットワーク
  • グローバル・サービスのリクエストがある。
  • マルチリージョン構成ではなくても必要なサービス
  • クラウドに関わらず、昨今のシステムでは、ネットワークは必要なインフラ
• グローバルサービス
  • Route53
    • コントロールプレーンは、バージニア州
    • データプレーンは、Edgeに分散している
    • 作成は、コントロールプレーンにリクエストしている
    • コントロールプレーンからデータプレーンは、伝搬される
    • Route53は、設計目標100%を活かすためには、ユーザ側の静的安定性が必要
      • シングルリージョンでも必要なケースが多い
• 静的安定性を支援するAWSサービス
  • Amazon Route53 Application Recovery Controllerを使う方法がある
    • 特徴：コントロールプレーンに依存せずに動作する
• グローバル・サービス
  • AWS IAM
    • IAMに関するユーザ側の静的安定性も大事。作成や更新を避ける
    • コントロールプレーンは、バージニア州
    • データプレーンは、各リージョンに分散している
    • 障害時IAMを作成することは、避けるべき
• ネットワーク可用性と冗長性は大事
• 利用者とのネットワーク
  • クリティカルなワークロードの高い回復姓
  • クリティカルなワークロードの最大回復性
  • AWS Site to Site VPN によるAWS Direct Connectの迂回経路の用意も有用
• ネットワークのユーザ側の静的安定性
  • 障害時に手動で書き換えは、静的安定性は低い。
    • 自動で書き換えるように設計する

感想

• 本セッションでは、ミッションクリティカルシステムを検討する際は、可用性とアーキテクチャが重要で、静的安定性と冗長化をセットで考える必要性を学びました、
  • 特に、静的安定性である「他のサービスが障害になっても、システムが影響を受けずに稼働する」と「障害復旧時に手作業などの特別なアクションを必要ないようにする」考えは、今後のアーキテクチャを考える上で参考になります。
  • また、ユーザ側でも「障害時にコントロールプレーンに新規作成や設定変更などを依頼しない」や「障害復旧時に手作業などの特別なアクションを必要ないようにする」といった点で、活かせることが理解できました。